home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 166 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.8 KB  |  97 lines

  1. Path: engnews2.Eng.Sun.COM!taumet!clamage
  2. From: vandevod@cs.rpi.edu (David Vandevoorde)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Observations on templates
  5. Date: 29 Jan 1996 19:15:51 GMT
  6. Organization: RPI Computer Science
  7. Sender: vandevod@avs.cs.rpi.edu
  8. Approved: clamage@eng.sun.com (comp.std.c++)
  9. Message-ID: <xso7mya95x9.fsf@avs.cs.rpi.edu>
  10. References: <ACVI83na99@qsar.chem.msu.su>
  11. NNTP-Posting-Host: taumet.eng.sun.com
  12. Content-Type: text
  13. X-Nntp-Posting-Host: avs.cs.rpi.edu
  14. In-Reply-To: "Eugene Radchenko"'s message of 29 Jan 96 10:38:37 GMT
  15. X-Newsreader: Gnus v5.1
  16. Content-Length: 3025
  17. X-Lines: 72
  18. Originator: clamage@taumet
  19.  
  20. >>>>> "E" == "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
  21. [...]
  22. E> 1) Clause [temp.res] verse 1 requires that all types dependent on the
  23. E> template parameter must be qualified by 'typename' keyword - supposedly to
  24. E> allow checking the template syntax. But it does not help anything as _each_
  25. E> instance will have to be checked anyway:
  26. [...]
  27.  
  28. I don't think that `typename' was introduced with the intention of avoiding
  29. instantiation checks. I expect at least one of the goals was to permit the
  30. development of more refined tools (e.g., for the analysis of generic as
  31. opposed to instantiated code).
  32.  
  33. E> 2) Clause [temp.dep] verse 5 states that base class scope names hide the
  34. E> template parameter:
  35. [...]
  36.  
  37. Although I didn't check the issue, I would tend to agree with you here.
  38. In particular, consider:
  39.  
  40.     template<typename B>
  41.     struct D: public B {
  42.         // Cannot guarantee that a member of B won't hide the
  43.         // classname itself.
  44.     }
  45.  
  46. Again, I didn't check this (i.e., what I say above may be unfounded).
  47.  
  48. E> 3) Clause [temp.arg.explicit] verses 2-3 requires that for explicit arg in
  49. E> member template to be present it must be qualified by 'template' keyword,
  50. E> e.g.
  51. E>      X *p; p->template alloc<200>();
  52. E> But to use operator -> we need X class definition anyway - so we know that
  53. E> alloc() is a template. Thus this keyword is redundant and likely to be
  54. E> forgotten (if I am not mistaken, it is in fact missing from some examples
  55. E> in lib.locale section).
  56.  
  57. Same as 1).
  58.  
  59. E> 4) Clause [temp.deduct] verse 4. Why the conversions other than Derived* ->
  60. E> Base* are not allowed in template deduction (at least default conversions
  61. E> like char->int; user conversions would be even better)?
  62.  
  63. I suppose this is a matter of avoiding complexity. Remember that the more
  64. possibilities the compiler must consider, the more time it will take to
  65. compile this code (and in this case we're talking about superlinear 
  66. growth). From a maintainability point of view, implicit conversion can
  67. also be a hassle.
  68.  
  69. [...]
  70. E> PS. Am I the only one who does not like the current drift in the C++ syntax
  71. E> from symbolic (C-like)
  72. E>    int a[10];
  73. E> to verbose (Pascal-like)
  74. E>    var
  75. E>      a: array[0..9] of integer;
  76. E> way of expressing things? Why don't use, for instance, cast_d instead od
  77. E> dynamic_cast (ugh). Yeah, I know we are not using 10-cps terminals Richie
  78. E> (sp?) did, but anyway... (and it consumes compiler memory space :-)
  79. [...]
  80.  
  81. I think that what you're observing is the tendency to require (or encourage)
  82. us to ``say what we mean''. The new casting syntax, the ban on implicit int,
  83. the explicit keyword, the uses of `typename' and `template' syntax that you
  84. mention and even the bool type are all ways to make more explicit in the
  85. source code what is going on. Considering the things that already happen
  86. automatically in C++ (virtual dispatch, template instantiation, destruction,
  87. user-defined conversions, ...), I am rather happy that those things that do
  88. not require transparency are made explicit.
  89.  
  90.     Daveed
  91.  
  92.  
  93. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  94.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  95.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  96.  
  97.